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(57) Abstract 

A server/client media file distribution system is provided in which the server system (12) is adapted to receive mnsmission requests 
from clients (14), status information from a network (16), and protocol information from each client (14). The server (12), based upon this 
information, adaptively transmits a given media file stored therein to one or more clients (14) using the optimal transmission speed and/or 
network protocol based on the network status information and protocol information. Additionally, the present invention provides a looping 
file arrangement in which a plurality of clients can receive the same media file on multiple netwo± channels, without the need to provide 
multiple copies of the same media file for each request of that file. 
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1 MEDIA FILE DISTRIBUTION WITH ADAPTIVE TR ANSMISSION 

2 PROTOCOLS 

3 The present invention is a continuation-in-part of Patent Application Ser. No. 

4 956,743 filed October 24, 1997 and assigned to the same assignee. 

5 BACKGROUND OF THE INVENTION 

6 1. Field of the Invention 

7 The present invention relates to media file distribution, and, more particularly, 

8 to a media file distribution system with adaptive transmission protocols in a 

9 networked client/server environment which provides automated, highly compressed, 

1 0 user-selectable media file distribution. Particular utility of the present invention is in 

1 1 less-than real-time server-client audio/video file distribution over conventional 

1 2 networks; although the present invention has equal utility in still image and/or high- 

1 3 resolution image file data distribution (e.g., x-ray, MRI, etc.). 

14 2. Description of Related Art 

1 5 Multimedia file distribution systems, which include distribution of audio 

16 and/or video information, are well known in the art. Examples include video-on- 

1 7 demand systems and network-based real-time streaming video systems and 

1 8 methodologies. Recent developments in high-speed network communications (e.g., 

1 9 ISDN, DSL, cable modems, etc.) have permitted the development of real-time 

20 streaming video data distribution in a client/server environment. Such systems 

2 1 typically employ extensive video file server systems that can transmit streaming video 

22 file data directly to a user's television set or PC (via, for example, Internet 

23 communications protocols (e.g., TCP/IP connections based on HTTP or FTP file 

24 transfer protocols). These systems typically transmit a separate copy of the streaming 
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1 video file to each receiver. This uses additional network bandwidth for each 

2 additional receiver. This can quickly lead to saturated networks, degrading the 

3 quality of the streaming video received, as well as impacting other users and uses of 

4 the network. Examples of such file distribution systems are described in U.S. Patent 

5 Nos. 5,132,992; 5,253,275; and 5,550,863 issued to Yurt et al., and hereby 

6 incorporated by reference. 

7 Conventional file transfer techniques use either the Transmission Control 

8 Protocol (TCP) or User Datagram Protocol (UDP) for the transmission of the data. 

9 These two protocols are part of the standard TCP/IP protocol suite. TCP is a 

10 connection-based protocol, meaning that there is a logical connection opened between 

1 1 the two systems involved in the transfer. Because of the connection, and the TCP 

12 protocol process, this connection is a "reliable connection." This means that packets 

13 are guaranteed to be received, intact and in order, or the connection is broken. 

14 Examples of common use of TCP would be browsing on the World Wide Web, File 

1 5 Transfer Protocol, sending and reading email, etc. 

16 UDP is a connectionless protocol, meaning that there is no open connection as 

17 you would find in a TCP session. Packets are transmitted by the sender and addressed 

18 to the receiver. UDP is not a "Reliable protocol". Packets in a UDP session, may be 

19 received out of sequence and may even be lost. Applications must either accept this 

20 loss, or implement some other means for ensuring reliability. Examples of common 

21 use of UDP would be Domain Name Service queries, RealAudio/RealVideo, network 

22 management functions, etc. Both TCP and UDP are designed for use between two 

23 systems. UDP can also be used for "Broadcast". Broadcast packets are limited to a 

24 single Local Area Network (LAN), and so will not cross any routers connected to that 
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1 LAN. 

2 Current development in the area of IP Multicasting are improving the art in 

3 areas such as reliability, performance, session management, network management, 

4 statistical research, router management, routing protocols, and other areas required for 

5 the smooth operation of IP Multicasting on public networks (e.g., The Internet). 

6 However, this art has not overcome the aforementioned problems: either the 

7 bandwidth requirements for multiple client access are too large, or the transmission 

8 protocol becomes unreliable. Moreover, the prior art is incapable of providing a 

9 system which can analyze client transmission demands and adaptively adjust the 

10 transmission protocols to most effectively accommodate a plurality of users. 

11 SUMMARY OF THE INVENTION 

12 Accordingly, the present invention solves the aforementioned drawbacks of 

13 the prior art by providing a server/client media file distribution system in which the 

14 server system is adapted to receive transmission requests from clients. The server 

15 also receives status information from a network, and protocol information from each 

16 client. The server, based upon this information, adaptively transmits a given media 

17 file stored therein to one or more clients using the optimal transmission speed and/or 

1 8 network protocol based on the network status information and protocol information. 

19 In the preferred system, the present invention provides a media file 

20 distribution system having a file distribution server system comprising a media file 

21 archive database in communication with one or more users over a network, said 

22 media file archive comprising one or more precompressed and pre-encrypted media 

23 data files, said server being for receiving one or more transmission requests for a 

24 selected media file from a plurality of users, the improvement comprising a file 

3 
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1 distribution system being adapted to receive a plurality of said transmission requests 

2 from a plurality of users, the transmission protocols of said plurality of said users and 

3 status information from said network and optimally simultaneously transmit said 

4 media file to each user based on said transmission protocols and said status 

5 information. 

6 Additionally, the present invention provides a looping file arrangement in 

7 which a plurality of clients oan receive the same media file on multiple network 

8 channels, without the need to provide multiple copies of the same media file for each 

9 request of that file. Also, the present invention provides multiple-level encryption 

10 technology that permits the server system to fully control both access and use of a 

1 1 given media file. 

12 It will be appreciated by those skilled in the art that although the following 

13 Detailed Description will proceed with reference being made to preferred 

14 embodiments and methods of use, the present invention is not intended to be limited 

15 to these preferred embodiments and methods of use. Rather, the present invention is 

16 of broad scope and is intended to be limited as only set forth in the accompanying 

17 claims. 

1 8 Other features and advantages of the present invention will become apparent 

19 as the following Detailed Description proceeds, and upon reference to the Drawings, 

20 wherein like numerals depict like parts, and wherein: 

21 BREIF DESRIPTION OF THE DRAWINGS 

22 Figure 1 is a block diagram of the media file client/server system of the 

23 present invention; 
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1 Figure 2 is a block diagram of the preferred network arrangement of the file 

2 distribution server system of the present invention; 

3 Figure 3 is a block diagram of the preferred media file database system of the 

4 present invention; 

5 Figure 4A is a block diagram of the preferred media file distribution system of 

6 the present invention; 

7 Figure 4B is a flow chart diagram of the preferred media file distribution 

8 system of Figure 4A; 

9 Figure 5 is a block diagram of one embodiment of the media file playback 

1 0 system of the present invention; 

1 1 Figure 6 is a block diagram of another embodiment of the media file playback 

1 2 system of the present invention; 

13 Figure 7 is a block diagram of another embodiment of the media file playback 

14 system of the present invention; and 

15 Figure 8 is a block diagram of the user control interface system of the present 

16 invention; 

17 Figure 9 A is a block diagram of convention network data transmission; 

1 8 Figure 9B is the preferred network data transmission of the present invention; 

19 and 

20 Figure 10 is a flowchart of the preferred server-client data transmission 

21 including the preferred de-encryption process of the present invention, 

22 It will be appreciated by those skilled in the art that although the following 

23 Detailed Description will proceed with reference being made to preferred 

24 embodiments, the present invention is not intended to be limited to these 

5 
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1 embodiments. For example, it should be understood from the outset that although 

2 preferably the functional components of the preferred embodiments of the system of 

3 the present invention are embodied as one or more distributed computer program 

4 processes running on one or more conventional general purpose computers (e.g., 

5 IBM-compatible, Apple Macintosh, and/or RISC microprocessor-based computers), 

6 conventional telecommunications (e.g., modem and/or ISDN means), networked 

7 together by conventional network hardware and software, other types of computers 

8 and network resources may be used without departing from the present invention. It 

9 should also be understood that the media file playback devices herein described can 

10 be embodied in various hardware forms, including: RAM/ROM drives, removable 

1 1 and/or permanent disk drives (including, but not limited to, hard disk drives, Jazz 

12 drives, and/or other removable media known in the art). Furthermore, it should be 

13 appreciated from the outset that one or more of the functional components may 

14 alternatively be constructed out of custom, dedicated electronic hardware and/or 

15 software, without departing from the present invention. Thus, the present invention 

16 is intended to cover all such alternatives, modifications, and equivalents as may be 

1 7 included within the spirit and broad scope of the invention as defined only by the 

18 hereinafter appended claims. 

19 Additionally, as used herein, the term "Unicast" describes a file transfer 

20 session between a single server and a single client receiver, using either TCP or UDP. 

21 The term "Multicast"(or more specifically "IP Multicast") describes a file transfer 

22 session between a single server and a plurality of client receivers. Because of the 

23 additional clients, all Multicast sessions must be based on the UDP protocol 
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1 as the TCP protocol specification does not allow for more than twb endpoints 

2 for the connection. 

3 DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

4 Figure 1 is a block diagram of the media file client/server system of the 

5 present invention. Shown in Figure 1 is a file distribution server 12 (which includes 

6 media file database system 1 8 and client database 20), a client (user) system 14 

7 (which includes a media file playback system 24), connected via a network system 

8 16. As an overview, the present invention is intended to provide media file 

9 distribution in a server/client environment. Media files can be any of feature films, 

10 television programs, audio files, or any other combination of audio and/or video 

1 1 programming. Further, media files can also contain non-media data. The following 

12 detailed description will be in reference to audio/video file distribution, and in 

1 3 particular, to full-length video file (i.e., feature film) distribution. The present 

14 invention is intended to permit a user to access the file distribution server, order an 

15 event (a movie), pay for the transaction via. the financial transaction server 22 (more 

16 fully described in copending application serial number 956,743), and receive the 

17 movie for later playback in one of a plurality of user playback devices. The present 

1 8 invention is preferably adapted to permit less-than real-time transmission of media 

19 files to one or more users using current networking technology (i.e., 28.8 and 56K 

20 modem technology) without having expensive and/or proprietary networking 

21 requirements placed on the user (i.e., such as those required by video-on-demand 

22 systems). Each of the functional components depicted in Figure 1 are discussed more 

23 fully below. 
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1 It should be understood at the outset that the present invention advantageously 

2 utilizes storage and transmission of precompressed and pre-encrypted file data 

3 (hereinafter referred to as "media file archive"), thereby eliminating the need for 

4 extensive processing power required for "on-the-fly" compression and encryption of 

5 media file data. This advantage is especially useful for full-length video files which, 

6 along with a soundtrack, would require massive amounts of storage to hold in an 

7 ' uncompressed form. In audition, by providing an airay of media files in 

8 precompressed format, the present invention is adapted to permit multiple, 

9 simultaneous download of a single media file, as will be described below. In 

10 addition, the preferred system of the present invention incorporates pre-encrypted 

1 1 media file data stored in the media file database. The encryption/de-encryption 

12 process (digital copy protection), described more fully below, preferably includes 

13 conventional and/or proprietary encryption algorithms that require users to obtain a 

14 valid decryption key for a given media file transmitted. 

15 Figure 2 depicts the preferred file distribution server arrangement of the 

16 present invention. Preferably, file distribution server installation 1 1 is comprised of a 

17 plurality (1 1A, 1 IB. . . 1 IN) of individual installations, each being located in 

18 geographically diverse areas, on individual power grids, e.g., each being located in a 

19 separate city, or within the same city on different power grids, thereby permitting the 

20 present invention to be fault-tolerant and maintain service to users in the event one or 

21 more servers should become off-line. Preferably each file distribution server 

22 installation is comprised of a plurality of request servers (13 A, 13B. . . 13N), and a 

23 plurality of media file servers (12A, 12B...12N). Each server (12 and 13) is 

24 preferably adapted with appropriate an network interface 48 A . . . 48N to permit one 

8 
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1 or more users access to the corresponding server over the network" 16. Those skilled 

2 in the art will recognize that network interface 48A ... 48 N can include of standard 

3 and/or proprietary networking hardware/software (e.g., TCP/IP networking 

4 hardware/software). Network 16 preferably includes a standard TCP/IP network 

5 (e.g., world wide web). Each server is also preferably adapted with conventional 

6 firewall hardware/software (not shown) to prevent unauthorized user access to media 

7 files stored therein. Also as shown in Figure 2, each server 12A . . . 12N is 

8 preferably in communication with the network traffic directors 50A. . .50N, via a 

9 heartbeat link. The heartbeat link is a status signal providing each server's respective 

10 status information, e.g., on-line/off-line, network overflow, user request data, etc. 

1 1 This heartbeat signal allows the network traffic director to route incoming requests to 

12 an operational server (12 and 13) able to service the request. In the event of a server 

13 failure, the network traffic director 50 A. . .50N will detect the failure and transfer the 

14 requests being handled by that server to another server (12 or 13) able to continue 

15 processing the request. Multiple network traffic directors 50A. . .50N are included in 

1 6 the preferred embodiment to prevent the network traffic director from becoming a 

17 single point of failure. Each network traffic director 50A..50N is active and handling 

1 8 requests. In the event of a network traffic director failure, the remaining network 

19 traffic directors will take over the additional load automatically. Thus, network 

20 traffic director 50A . . . 50N is adapted to receive network status messages, heartbeat 

21 link status messages, and individual user request messages, preferably in real-time, to 

22 permit the network traffic director to route incoming requests based on these criteria. 

23 Additionally, the traffic director monitors the transmission protocol and transmission 
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1 speed of each client, anci uses this information to optimally transmit a given media 

2 file to one or more clients. 

3 As shown in figure 2, requests from users are received by the network traffic 

4 director 50A. . . SON, which forwards those requests to the request server 1 3 A. . . 1 3N. 

5 The response is sent back to the user by the request server. This response includes 

6 information of the client software used to contact the media file server 12A. . . 12N. 

7 The media file server transrhits the requested media file using industry standard 

8 and/or proprietary network protocols. These protocols are described further below. 

9 Media file server 12A. . . 12N is adapted to monitor the incoming user request 

10 messages and determine an overall throughput value based on the current users' 

1 1 transmission speed. In addition, the media file server 12A. . . 12N will monitor 

12 network performance during the transmission of the media file, adapting the 

13 transmission speed to optimally accommodate the transmission speeds of all the users 

14 currently viewing the media file. Thus, the transmission speed of the server can be 

15 automatically adjusted based on the average throughput speed of the users currently in 

16 communication with the server, and/or based on the lowest transmission speed 

17 available (thereby providing transmission at a least common denominator speed). 

18 The preferred embodiment includes multiple transmissions for each media file, each 

19 being at different speeds. These channels allow users to receive data from the 

20 channel most closely matching the throughput of their connection. This also allows 

21 high-speed client systems to be segregated from the lower-speed systems. This 

22 segregation provides the optimal throughput for each user. Although not shown in the 

23 drawings, each server (12 and 13) and network traffic director 50 preferably includes 

24 a back-up power supply (e.g. battery back-up power supply system) to permit the 

1 r\ 
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1 device to achieve the stated functionality in the event of a power failure, without 

2 interrupting service to the users connected thereto. To that end, each device is 

3 adapted to monitor the status of the back-up power supply and, when enabled, provide 

4 a "fail-over** to another on-line server capable of providing the required functionality. 

5 Turning to Figure 3, the processing steps necessary to create the media file 

6 archive 26, advertisement archive 34, and plug-in archive 30 elements for storage in 

7 the media file database 18 is depicted. The data is divided into blocks or frames, each 

8 frame having a header and payload section. The header information is normally not 

9 processed, but contains information about the processing applied to that frame. The 

10 data payload is what is actually processed. To create the media file archive 26, the 

1 1 raw media file 25 is preferably processed using compression technology 27A. This 

12 compression technology includes one or more of a variety of compression techniques, 

13 including MPEG I, II, IV, and /or other compression techniques known in the art, or 

14 may include proprietary and/or custom compression algorithms (such as provided by 

15 Iterated Systems, Inc, or as described in U.S. Patent No. 5,420,942, hereby 

1 6 incorporated by reference). 

17 Although optional, nearly all media files will be compressed. The compressed 

18 file is then preferably processed to add a digital watermark 32 A. Not all files will 

19 require watermarking, and in fact some files must not be watermarked. In these 

20 cases, the watermark process is bypassed. The watermark, if applied, provides 

21 source identification used to identify the file later. Further processing provides digital 

22 protection of the media file by encrypting it using strong encryption algorithms 46 

23 such as CAST- 128, IDEA, Triple-DES, or other high-grade encryption technology. 

24 Not all, but most media files will require encryption. The resulting media file archive 

11 
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1 26, which has been optionally compressed, watermarked, and encrypted, is stored in 

2 the media file database 1 8 associated with a collection of media file distribution 

3 servers 12. 

4 Also shown on Figure 3, media files provided by advertisers are also 

5 processed using compression 27B and watermarking 32B, providing the same 

6 benefits as described above. Advertisements are not encrypted. The resulting 

7 advertisement archive 34 is stored in the media fire database 18 for later retrieval. For 

8 example, the watermark can include identification information (which may include, 

9 for example, originating ownership information of a given media file, etc.) and may 

10 also include copyright notice information. Module 34 is provided for those suppliers 

1 1 of media file data who also wish to include a trailing or ending advertisement, which 

12 is incorporated into a media file upon transmission to a user. To that end, module 34 

13 also includes an updatable database (not shown) which contains advertisements, and 

14 also association parameters that can direct certain advertisements to be incorporated 

1 5 with certain media files. Thus, the present invention permits advertisers to provide 

16 advertisement data to the system. The advertisers can choose which media file(s) 

17 their ads are to be associated with, and those associations are preferably automatically 

1 8 affixed to the appropriate media file upon transmission. The advertising data can be 

19 affixed to the media file as a trailer and/or leader. Modules 28 and 30 are discussed 

20 more fully below with reference to Figure 8. 

21 Also shown on Figure 3, plug- in and CODEC program source files 29 are 

22 processed and compiled 3 1 to produce a plug-in and CODEC module archive 30 

23 which is stored in the media file database 18. As executable programs, they can be 

24 neither watermarked or encrypted, as such processing would render them unusable. 
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1 The encryption module 46 processes the media file by generating a random 

2 key which becomes the master key for the file. This master key is saved in a key 

3 database (not shown). For each block, a new random frame key is generated. This 

4 key is combined with the master key and the resulting key used to encrypt the payload 

5 of the frame. The frame key is saved in the frame header. This information will be 

6 used later to decrypt the data payload, a process described below with reference to 

7 Figure 10. 

8 Figure 4A depicts the preferred embodiment of the file distribution server 12 

9 and the relationships between that server and the media file database 18. As an 

10 overview, the present invention is adapted to permit multiple users access to the same 

1 1 media file (e.g., movie, image, etc.), thereby eliminating the need for multiple copies 

12 of a single media file. Further, the preferred embodiment of the file distribution 

13 server 12 uses network software and protocols to allow multiple users to access the 

14 same media file stream, reducing the network bandwidth required, thus reducing the 

1 5 impact on the Network. In the present invention, n-requests for media file content are 

16 transmitted by n-users over the network and received at the appropriate server (or, 

17 rerouted to a server having the selected media file), and are received by the request 

18 processor 36 running on that server. Each request is for a single media file archive, 

19 advertisement archive, or media plug-in or CODEC. Multiple requests can be issued 

20 by a client system, each to be processed by the server and handled individually. 

21 The requests are processed and passed to the protocol control module 38 for 

22 further processing in preparation for transmission. The protocol control module 

23 preferably passes the request to the multicast protocol processor 40, which attempts to 

24 establish a multicast pathway between the customer system 14 and the media file 

13 



WO 00/64111 



PCT/US00/10126 



1 server 12. If a multicast connection cannot be established, for whatever reason (e.g., 

2 lack of multicast support by the Internet Service Provider used by the customer 

3 system 14 to connect to the Internet), the protocol control module will pass the 

4 request to the unicast protocol processor 42 for establishment of a connection using 

5 the User Datagram Protocol (UDP), which is part of the standard TCP/IP network 

6 support. 

7 Once the data connection is established, whether.by multicast or unicast, me 

8 appropriate protocol processing module requests packets of information from the 

9 packet assembly module 44. The information necessary to assemble the packets for 

10 transmission is retrieved from the appropriate section of media file database 18. 

1 1 Further clarification of this process is provided below with reference to Figure 4C. 

12 Referring to Figure 4b, the preferred embodiment the media archive database 

13 18 is stored on media file storage device 40. In the preferred embodiment, the media 

14 file storage device 40 includes a plurality of media file storage devices 40A. . .40N, 

15 consisting of one or more archive systems, for example, CD-ROM/DVD-ROM media 

16 devices, hard drive devices, or other digital media storage devices. 

17 Referring to Figure 4C, the steps for processing requests is described as 

1 8 follows. The operational flow 50 contains the flow of processing, while Figure 4A 

19 shows the relationship between the subsystems of the media file server. Requests are 

20 received 52 by the request processor 36. If the requested file is not available on this 

21 server 54, the client system is redirected to a server with the requested file 55. The 

22 request is passed to the protocol process module 38. This modules controls the 

23 establishment of the network connection between the file distribution server 12 and 

24 the customer system 14. Preferably, this connection will use a multicast protocol, if 

14 



WO 00/64111 



PCT/US00/10126 



1 possible. Thus, the multicast protocol module is invoked (if possible) to establish the 

2 multicast channel. First, the active channel list is consulted to determine if the 

3 requested event is already active on a multicast channel 56. If so, the channel 

4 information is sent to the client system 57. The client system uses this information to 

5 open the multicast channel using standard IP multicasting protocols such as DVMRP 

6 and PIM. If the event is not currently being transmitted, a new multicast channel is 

7 created, and synchronization packets are sent on this channel 59. These SYNC 

8 packets give the client system 14 something to verify receipt of data on the multicast 

9 channel without actually beginning the event until it is certain the data can be 

10 received. If the client system is not able to begin receiving the multicast data within a 

1 1 given timeframe 58 and 60, the unicast protocol module is invoked in an attempt to 

1 2 use the UDP protocol instead 6 1 . 

13 Once the channel is opened, data packets for the event are assembled by the 

14 packet assembly module 44, which is sent to the multicast protocol module 40 and 

15 unicast protocol module 42 for transmission on active channels for that event For 

16 efficiency, the same packets are used for transmitting to all open channels for the 

1 7 event, whether they are multicast or unicast channels. 

1 8 The same data stream is received by all client systems 14 actively receiving 

19 the event. Each client system will have started receiving the event data at a different 

20 point in data stream. The event data stream continues to be transmitted until the end 

21 of the event is reached 66. At this time, the event data stream is restarted from the 

22 beginning 62. Client systems continue to receive the event data until they have 

23 received the entire event 64. As each client completes the event, these clients systems 

24 notify the appropriate protocol module of the change in status 65. The "Loop" 
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1 continues until all active client systems have completely received the event data. 

2 When there are no active clients monitoring a channel, the event data transmission is 

3 stopped and the channel is closed. 

4 Referring to Figure 4d, the receive loop is described. A packet is received 200 

5 and written 210 to the local storage device on the client system 14. Each packet is 

6 serialized, and if the packet received was not the packet expected 220, some data may 

7 be missing. If tire serial number of the packet that of a packet previously missing, 

8 then the NAK table is updated to remove the entry corresponding to the previously 

9 missing packet, and any timers running on that data packet are stopped 250. If one or 

10 more packets are identified as missing 220 and 230, then a NAK packet is generated. 

1 1 In the case of a unicast connection 260, the NAK is sent immediately 280, otherwise 

12 the NAK suppression timer is started (Timer "A") 270 and processing of this 

13 incoming packet ends. If during the cycle of the NAK suppression timer, a NAK is 

14 received on the control channel 300 for the same packets missed by the client system 

15 310, then the NAK suppression timer is stopped and the NAK data timer is started 

16 320. When either of the timers expire, the previously generated NAK packet is 

17 transmitted to the server on the multicast control channel 280. The NAK data timer is 

18 restarted 290. The NAK cycle continues until there are no outstanding missing 

19 packets. 

20 The difference between conventional network data transmission and that 

21 provided by the present invention is shown pictorially in Figures 9A and 9B, 

22 respectively. In Figure 9A, multiple customers are seeking access to the same media 

23 file. To support simultaneous transmission in the conventional system, the media file 

24 must be duplicated at the time of transmission, one copy for each request instance 
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1 (which significantly adds to the overall bandwidth requirements of the service). 

2 Alternatively, as shown in Figure 9B, users are permitted simultaneous transmission 

3 of the data file at the temporal location in which a request is received, and the media 

4 file continually "loops around" to ensure each customer receives the entire media file. 

5 In the present invention the network bandwidth requirements are significantly 

6 reduced, since only a single instance of a media file is being transmitted over the 

7 network. 

8 Turning now to Figures 5-7, separate preferred embodiments of the media 

9 file playback system 24 are depicted. In the embodiment of Figure 5, a self-contained 

10 system (for example, a "set-top" system) 24' is provided which includes a 

1 1 communications interface, a user interface and associated hardware to permit a user to 

12 communicate to the file distribution server 12, order a desired media file and receive 

13 and play the media file using system 24' . Each of the functional components of 

14 Figure 5 are described below. 

15 System 24' includes a network interface 70 (e.g., modem, etc.) permitting 

16 two-way communication between the user of system 24' and server 12, via network 

17 16. A user interface 80 is provided to permit communication between the system 24' 

18 and a user. For example, user interface 80 can include a remote controlled interface 

19 that is displayed in a menu format (using display 84) whereby a user can chose among 

20 various options. In addition to, or alternatively, the remote controlled user interface 

21 80 can include an input device (e.g. keyboard, etc.) to permit a user to enter 

22 commands to system 24'. The user interface is described more fully below in 

23 reference to Figure 8. In essence, a user is permitted to enter one or more commands 

24 related to the transmission of one or more desired media files. These commands are 
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1 temporarily stored on temporary storage 72. Temporary storage 72 can include a 

2 combination of RAM memory and permanent memory (e.g., hard disk) for storage of 

3 user-generated commands and for temporary storage of the selected media file. Upon 

4 entering commands, system 24' initiates communication with server 12, via network 

5 16. It should also be noted that user interface 80 preferably also includes commands 

6 to permit a financial transaction to occur using financial transaction server 22, which 

7 permits a user to enter financial information (e.g., credit card information, etc.) to 

8 purchase the media file. Server 12 begins transmission of the media file, in 

9 accordance with the above-described embodiments. The media file is temporarily 

10 stored in temporary storage 72. 

1 1 Upon the appropriate command from user, the media file temporarily residing 

12 in temporary storage 72 is accessed to be played. Upon such commands, the media 

13 file is sent to decompression and de-encryption 74 to decompress and/or de-encrypt 

14 the media file. Decompression and de-encryption includes appropriate 

15 hardware/software to achieve the stated functionality. Of course, decompression 

16 hardware and software are adapted to decompress a given media file in accordance 

17 with the pre-compressed media file, or to decompress the media file in accordance 

18 with compression and encryption 46 performed on the server side. To that end, the 

19 media file, as sent by the server system, may also include appropriate plug-in modules 

20 or CODECS, which may include one or more self-executing structured files, for a 

2 1 given compression/decompression scheme. In addition to media file selection 

22 performed by the user, the system 24' of the present invention also preferably 

23 includes means to generate a unique passwordable encryption information. This 

24 information can include a user-supplied password, or, alternatively, may include a 
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1 serial number automatically generated by system 24'. The encryption information is 

2 forwarded to the server along with the media file request commands, and the server 

3 encrypts the file accordingly, using, for example, public-key or other encryption 

4 technology. Using the information generated by the system 24' and the server, the 

5 media file is de-encrypted. 

6 As noted above, media file preferably includes time stamp data. This 

7 information is used both as a temporal marker for transmission purposes on the server 

8 side (discussed above), and as a time limiting marker associated with the media file. 

9 Once the media file is decompressed and/or de-encrypted, the file is sent to a copy 

10 protection generator 76. Preferably, copy protection generator 76 is a digital signal 

1 1 processing that encodes the media file with analog copy protection. Analog copy 

12 protection includes coding that is generated within the data file that inhibits the file 

13 from being transferred to another medium, for example, video cassette, by ensuring 

14 that any such copy is significantly degraded in quality. Copy protection hardware, 

15 such as provided by Macrovision ®, include appropriate coding for a given media file 

16 type to be displayed in a preselected format (e.g., VGA, HDTV format, NTSC format, 

17 etc.). Preferably, copy protection 76 also includes the ability to add time limiting data 

18 that limits the viewable lifespan of the media file. Thus, for example, using the time 

19 stamp data generated by server, the copy protection generator can incorporate time 

20 limiting data, for example, 24 hours, into the media file, after which the media file is 

21 erased from the system 24'. Alternatively, copy protection generator 76 can include 

22 an automatic erase mechanism that erases the file as it is being viewed. 

23 Once copy protection has been incorporated into the media file, the file is sent 

24 through a D/A converter 78 to convert the file into the appropriate output, e.g., 
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1 HDTV, NTSC, VGA, etc., and is sent to a display 84, via display interface 82. 

2 Display 84 can include an analog display that is adapted to play the particular media 

3 file (e.g., HDTV, NTSC, PAL, etc.). Display interface 82 includes one or more 

4 interface jacks 82A . . . 82D for connection to a particular display 84. For example, 

5 jacks 82A ... 82D can include an RCA jack, an input jack, a video out jack, etc. In 

6 addition, the media file may also include sound data (e.g., soundtrack data). Thus, 

7 interface 82 may further include sound output jacks (which may also include 

8 appropriate interfaces for Dolby™ Surround Sound connections, as are known in the 

9 art). 

10 Figure 6 depicts a PC embodiment of the media file playback system 24' '.In 

1 1 this embodiment, the media file is transmitted directly to a user's PC and the PC is 

12 appropriately adapted for direct viewing of the media file on the computer's monitor 

13 or separate display. To that end, system 24" includes a network interface 70, which 

14 includes appropriate hardware/software to permit the user to access the file 

15 distribution server 12 via the network 16. As in the previous embodiment, a user 

16 enters commands, via user interface 80, to transmit signals to the server to select a 

17 desired media file. The media file is transmitted and decompressed and/or de- 

18 encrypted 74 and stored on a removable media device 86. Removable media can 

19 include an Iomega Jazz disk, memory disk, hard disk, etc., and/or other portable 

20 storage devices known in the art. Referring to Figure 6A, removable media includes 

21 temporary storage 72 to hold the media file, and is preferably adapted with on-board 

22 copy protection 76 (described above). A removable media player 88 is used in 

23 conjunction with the specific removable media type to display the media file on a 

24 display 84. In the preferred embodiment, the removable media device 86 is adapted 



WO 00/64111 



PCT/US00/10126 



1 to be able to interface with a standard VCR player. Thus, removable media device 

2 includes appropriate hardware to permit the video information to be fed to the analog 

3 head arrangement common to all VCRs. Alternatively, the removable media device 

4 can be played in an appropriately adapted media file playback system 24\ described 

5 above. 

6 In the system 24* ' ' depicted in Figure 7, a PC is used to obtain a media file 

7 from the server, and the media file is transmitted to a local display or a remote display 

8 using a remote transmission and reception system. The PC operates as described 

9 above with reference to Figure 6. Upon output of the PC, the media file signals are 

10 sent to a converter 90. The converter 90 converts the media file from the chosen 

1 1 digital download format (e.g., VGA, etc.) to the appropriate display format, for 

12 example NTSC, HDTV, etc. In one form of this embodiment, the converted signal is 

13 sent to a standard wall outlet transmitter/receiver 92, 94. The transmitter/receiver 92, 

14 94 can be supplied by VideoCom, Inc. The transmitter 92 is coupled to the internal 

15 wiring of the building (e.g., copper home and/or office wiring, etc.) which typically 

16 operates on 120 VAC at 60 Hz. The media file signals are modulated and sent to 

17 receiver 94, where the signals are demodulated and displayed on a display 84. 

1 8 Alternatively, the system 24* " can include and RF transmitter 96 and receiver 98 to 

19 transmit the media file signals to a remote display 84. RF transceivers, as are known 

20 in the art, include radio frequency modulation of the signals to broadcast the signal in 

21 a wireless manner. Of course, the modulation frequency can be chosen for a given 

22 environment and/or distance between transmitter 96 and receiver 98. Those skilled in 

23 the art will recognize that the PC depicted in Figures 6 and 7 includes all the 

24 necessary hardware/software to achieve the stated functionality, including that 
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1 hardware/software to achieve communication and interaction with the server to order 

2 and transmit media files. 

3 Referring now to Figure 8, the preferred user interface of the present invention 

4 is depicted in block diagram form. It should be noted that the functionality associated 

5 with the interface modules described below are preferably accomplished through 

6 appropriately programmed windowed environments and operating systems (e.g., 

7 Unix, Windows, Windows NT, Apple OS, etc.) as may be applied to the embodiments 

8 shown in Figures 6 and 7 above. Alternatively, a proprietary menu-driven 

9 environment may be used for the embodiment shown in Figure 5. It should also be 

10 noted that the interface modules shown in Figure 8 are only exemplary, and any of the 

1 1 stated functionality herein can be accomplished through an appropriately program 

12 module. As discussed herein, users are permitted to choose among various 

13 functionality when ordering a video file for transmission from the server. For 

14 example, certain video files will be stored on the server in a plurality of formats and 

15 pixel dimensions (e.g., VGA, letterbox, etc.), resolutions, frame rates, etc. 

16 Accordingly, a user may select a particular media file in a desired bit depth 100, 

17 language 104, aspect ratio (pixel dimension) 106, media file format 108, or sound 

18 feature (e.g., full stereo sound, mono sound, Dolby enhanced sound, etc.). The user 

1 9 may also choose a desired frame rate 1 1 8 or artifact filter selection (as may be 

20 associated with a certain compression technology) 116. Additionally, the user may 

21 select a transmission protocol (e.g., HTTP, FTP, etc.) 1 10, select a transmission start 

22 time 112 and/or a preferred server transmission location 122. Also, as noted above, 

23 the user interface also preferably includes appropriate software to permit users to 

24 create templates 120 that are added to a media file. 
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1 Figure 10 depicts a flow chart of the preferred server-client data transmission 

2 including the preferred de-encryption process of the present invention. It should be 

3 noted that the flow chart shown in Figure 10 incorporates the description discussed 

4 above with reference to Figures 1-9, In the media file transmission system of the 

5 present invention, a user queries the server for a media file 128. If appropriate, the 

6 user supplies user-selectable data (i.e., that data associated with the user interface in 

7 Figure 8) 130. The server determines the user's parameters 132, i.e., transmission 

8 protocol, etc. In addition, the server determines if the user has the appropriate plug- 

9 in programs and/or CODECS for a given media file. The user is prompted for 

10 payment information, and the server conducts a financial transaction 134. As 

1 1 described above, the preferred system stores files requiring encryption protection in 

12 encrypted form on the server systems storage devices 18. This encryption was 

13 performed using a unique, random key selected for each event requiring encryption 

14 protection. This encryption key is stored in a secure area of the server. The key for 

15 the given event is processed to cryptographically split the key into two parts. One 

16 part is placed into the play ticket provided to the user. The other part is placed into a 

17 validation database located in a secure area of the server. Both the play ticket and the 

18 media file are transmitted to the user 140 and stored locally on the user's system. The 

19 user attempts to play the media file 142. The play ticket interrupts the access to the 

20 media file, and automatically communicates with the server for validation 144. If the 

21 play ticket is valid, the server sends the second part of the decryption key 146, which 

22 when combined with the part from the play ticket results in the decryption key unique 

23 to the encryption of the media. Once the decryption key is recovered, both parts of 

24 the divided key are purged from the system. On the user's side, the decryption key is 

23 



WO 00/64111 



PCT/US00/10126 



1 used to decrypt the media file 148. Thus, preferably, the decryption key remains 

2 resident in RAM and cannot be written to permanent storage. The user con then view 

3 the media file once only. If the user wishes to view the file more than once, process 

4 142-150 discussed above repeats. As the play ticket has been used once, a new play 

5 ticket must be retrieved from the server. Preferably this new play ticket will not 

6 require the user to download the media file to replay, although some media files will 

7 be required to be purged from the system as they are playing. ? 

8 Thus, it is evident that there has been provided a media file distribution system 

9 having adaptive transmission protocols that satisfies the aims and objectives set forth 

10 herein. Accordingly, the present invention is intended to be of broad scope, and only 

1 1 limited by the appended claims. 
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1 CLAIMS 

2 1, In a media file distribution system having a file distribution server 

3 system comprising a media file archive database in communication with one or more 

4 user systems over a network, said media file archive comprising one or more 

5 precompressed and pre-encrypted media data files, said server being for receiving one 

6 or more transmission requests for a selected media file from a plurality of users, the 

7 improvement comprising a file distribution server system being adapted to receive a 

8 plurality of said transmission requests from a plurality of user systems, the 

9 transmission protocols of said plurality of said user systems and status information 
10 from said network and optimally simultaneously transmit said media file to each user 



1 1 system based on said transmission protocols and said status information. 

12 2. A media file distribution system as claimed in claim 1, wherein said 

13 media file distribution server system comprises a plurality of said server systems, 

14 each being geographically located remote from one another. 

15 3. A media file distribution system as claimed in claim 2, wherein each 

16 said remote file distribution server system includes a status signal transmitted and 

17 received by each file distribution server system, said status signal reflecting the 

18 operational parameters of the file distribution server system. 

19 4. A media file distribution system as claimed in claim 1 , wherein each 

20 said file distribution server system comprises a network interface for communicating 

21 over said network. 

22 5. A media file distribution system as claimed in claim 1 , wherein said 

23 file distribution server system is adapted to receive signals indicative of the network 
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1 transmission speed of said users and to optimally transmit said media file to said users 

2 using the transmission speeds of the users. 

3 6. A media file distribution system as claimed in claim 1 , wherein said 

4 file distribution server system is adapted to receive multiple transmission requests 

5 from multiple users and to transmit a media file to each user at substantially the 

6 transmission speed of each user. 

f 7; A media fire distribution system as claimed in claim 1, wherein said 



8 file distribution server system further comprises an advertisement archive data base 

9 comprising advertisement data, and a plug-in archive data base comprising one or 

10 more programs related to said media data files. 

11 8. A media file distribution system as claimed in claim 1 , wherein said 

12 precompressed media data file is compressed using MPEG 1 , MPEG 2, and/or MPEG 

13 4 compression algorithms. 

14 9. A media file distribution system as claimed in claim 1, wherein said 

15 media file distribution system server system also adapted to transmit a decompression 

16 algorithm corresponding to said precompressed media file to said user system. 

17 10. A media file distribution system as claimed in claim 1 , wherein said 

1 8 media file archive comprises a storage device. 

19 11. A media file distribution system as claimed in claim 1, wherein said 

20 network comprises a TCP/IP based network. 

21 12. The file distribution system as claimed in claim 1, wherein said media 

22 file distribution server system is adapted to receive a plurality of transmission 

23 requests for a single media data file and transmit said media data file to each said user 
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1 based upon the current transmission location of said data file within said storage 

2 device. 

3 13. The media file distribution system as claimed in claim 10, wherein said 

4 storage device comprises one or more hard disk devices, CD rom/dvd rom devices, or 

5 digital media storage devices. 

6 14. A media file distribution system as claimed in claim 1, wherein said 

7 media file distribution server system is adapted to transmit said media file to each 

8 said user using a multi-cast protocol module. 

9 15. A media file distribution system as claimed in claim 1, wherein said 

10 media file distribution server system is adapted to transmit said media file to each 

1 1 said user using a unicast protocol module. 

12 16. A media file distribution system as claimed in claim 1, wherein said 

13 file distribution server system is adapted to transmit said media file to each said user 

14 as a plurality of packets, and wherein each said user system is adapted to monitor the 

15 transmission of said packets, and to notify said file distribution server system of a 

16 packet that is not received by said user. 

17 17. A media file distribution system as claimed in claim 1, wherein said 

18 file distribution server system is adapted to transmit a single media data file 

19 simultaneously to a plurality of said users over said network. 

20 18. A media file distribution system as claimed in claim 1, wherein said 

21 media file distribution server system comprises an encryption key data base, wherein 

22 said encryption key data base stores encryption keys related to each said encrypted 

23 media data file, and wherein upon transmission of said encrypted data media file to 

24 said user, a matching de-encryption key is provided to said user. 

27 
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1 19. A media file distribution system as claimed in claim 18, wherein said 

2 de-encryption key is adapted to interrupt access of said media data file by said user 

3 and automatically initiate a communication with said server system for validation of 

4 said de-encryption key. 
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